With the rise of the interconnected computer networks such as the Internet, it is possible to construct complex transaction-based applications that are distributed over several networked computers. In the simplest scenario, in general, these transaction-based applications function in the following way. A software application program, which executes on a client, initiates a transaction that requires access to services provided by a distant computer, called a server. Examples of these services could be an update to a database such as a bank's database, an execution of a purchase order such as in the case of purchase of a security and the like. Typically, the client sends a “request” message to the server, which then sends a “response” message containing a response to the request.
Typically, the server is not a single computer, rather a collection of interconnected heterogeneous computers. The request message is then formatted in such a way that all the interconnected computers can understand and respond to the request message. If the collection of interconnected computers is configured in an object-oriented programming model, then software object (or objects) that are capable of working together to provide a response to the request message can be distributed among the several computers. But in order to access the objects from a remote computer the objects must somehow publish their existence, their addresses, their properties, the services they provide, and other details to the “outside” world. Then, a client may be able to use the services provided by sending a request message in a manner similar to making a remote procedure call (“rpc”) and obtaining a response to that message.
Various paradigms exist as a result of the need to standardize the methods by which objects can be distributed and accessed over a network. These are Microsoft Corporation's Distributed Component Object Model (DCOM), JavaSoft's JAVA™ (hereafter, JAVA)/Remote Method Invocation (JAVA/RMI), and Object Management Group's Common Object Request Broker Architecture (CORBA™, 1076 hereafter CORBA).
Though some differences are present among these models, they principally work in the following way. Objects that provide services are typically located on servers. These objects are queried by applications running on clients using a specified data communication transport layer protocol—the Object Remote Procedure Call (ORPC) for DOOM; the JAVA Remote Method Protocol (JRMP) for JAVA/RMI; and the Internet Inter-ORB Protocol (IIOP) for CORBA. A client suitably formats a query message in the appropriate protocol language and transmits the query message, which is routed to the appropriate server, whereupon it is executed, and a response message is formatted and routed back to the client. As referred to herein, the term “object” may mean the object definition, associated operations, attributes, etc., and implementation for that object. As will be appreciated by those of skill in the art, at times the term “object type” is used to refer to the definition of the operations and attributes that software external to the object may use to examine and operate upon the object. The “object type” is also known as the “interface.” Also, the term “object,” may be used to refer to an actual run-time instance of an object and will be made clear by the context.
A server configured to be a JAVA/RMI server comprises objects that have predefined interfaces, which can be used to access the server objects remotely from another machine's JAVA A Virtual Machine (JVM). A JAVA/RMI sever object interfaces declare a set of methods that indicate the services offered by that sewer object. A program resident on the sewer called an RMI Registry stores and makes available to clients information about server objects. Typically, a client object obtains information regarding the methods and other properties of a server object by performing an operation such as “lookup” for a server object reference. This lookup typically works by the client object specifying an address in the form of a Universal Resource Locator (URL) and transmitting the address to the server's RMI Registry.
The clients and sewers also include interceptors. The interceptors provide hooks to programmers to execute their piece of code at certain points during (ORB™ (hereafter, ORB). Typical uses of the interceptors include: transaction service integration, security message compression and encryption, fault tolerance and other operations such as tracing, profiling, debugging, logging.
In CORBA, each CORBA object transparently interacts with an Object Request Broker (ORB), which provides a means to access either local or remote objects. The ORB is essentially a remote method invocation facility, and forms the lowest layer of the several layers in CORBA. Each CORBA server object exposes a set of methods, and it declares its interface. A CORBA client obtains an object reference and determines which methods are provided by the object. A CORBA client needs only two pieces of information: a remote object's name, and how to use its interface. The ORB is responsible to locate the object, provide a vehicle by means of which a query is transmitted to a server object and a response is transmitted back to the client object. In general, a CORBA object interacts with an ORB by either using an ORB's interface or using an Object Adapter.
There are two kinds of object adapters, the Basic Object Adapter (BOA.) and the Portable Object Adapter (POA). The BOA (or the POA) typically has methods for activating and deactivating objects, and for activating and deactivating the entire server. These are intended for systems where the ORB and the server are separate programs or even on separate machines. Different vendors supplying CORBA-compliant servers ordinarily choose one or the other of these methods of an object-ORB interaction.
As described above, CORBA, objects take form within server applications. In a server, CORBA objects are implemented and represented by programming language functions and data. The programming language entities that implement and represent CORBA objects are called servants. A servant is an entity that provides a body for a CORBA object, and for this reason, the servant is said to incarnate the CORBA object.
Object adapters such as the CORBA-standard Portable Object Adapter (POA) mediate between an ORB and a set of programming language servants. In general, though there could be many instances of POAs to support CORBA objects of different styles, and all server applications have at least one POA called the Root POA. Each POA instance represents a grouping of objects that have similar characteristics. These characteristics are controlled via POA policies that are specified when a POA is created. The Root POA, which is present in all server applications, has a standard set of policies. POA policies are a set of objects that are used to define the characteristics of a POA and the objects created within it. The CORBA standard specifies that interfaces for POA, POA manager (which is a class to manage multiple POAs) and the POA policies are defined in a standard module.
The above discussed technologies have been utilized in the Internet. However, the next phase of the Internet revolution is predicted to be interconnection of isolated Internet systems with the systems that run the business to create a responsive, flexible, scalable, and differentiated eBusiness enterprise. The information systems that connect eBusiness with the enterprise are coming to be known as enterprise portals.
Enterprise portals can act as new storefronts, new front-offices, new sales and support agents for the enterprise, with profound implications. Enterprise portals will leverage an enterprise's processes, data, and transactions on the Internet. They will simplify access to a mix of Internet and non-Internet applications, built with heterogeneous formats, platforms, protocols and software. This universe of diverse content, interactions, transactions, and application functions will require new methods of organization and management, particularly to keep up with frequent changes in the business.
The enterprise portals are becoming popular because the Internet affords large opportunities to extend business and invent new business models. Enterprise portals hold the key for these established companies to “bricks and clicks” strategies that weave online services with their existing channels, production facilities, and other business elements into a powerful combination.
Enterprise portals require scalable, flexible and open distributed platforms, the ability to leverage and extend the full range of resources inside and outside of the corporate walls, and the ability to accommodate rapid, continual change. At their root, enterprise portals host a different kind of application—the composite application.
Composite applications combine new business logic with existing logic, processes, and data to meet business needs. A new system is required to provide all of the components of an enterprise portal infrastructure. This new set of server-based products marshals the company's expertise in design and support of enterprise systems from diverse applications using object and component technologies.
Whatever the precise merits, features, and advantages of the above cited references, none of them achieve or fulfills the purposes of the present invention.